Agents
A software agent is a software abstraction, similar to the object-oriented programming concept of an object. The concept of an agent provides a convenient and powerful way to describe a complex software entity that is capable of acting with a certain degree of autonomy in order to accomplish tasks on behalf of its user. But unlike objects, which are defined in terms of methods and attributes, an agent is defined in terms of its behavior.
Various authors have proposed different definitions of agents, commonly including concepts such as:                Persistence—code is not executed on demand but runs continuously and decides for itself when it should perform some activity        Autonomy—agents have capabilities of task selection, prioritization, goal-directed behavior, decision-making without human intervention        Social Ability—agents are able to engage other components through communication and coordination, they may collaborate on a task        Reactivity—agents perceive the context in which they operate and react to it appropriately.        
Agents may also be mobile. They can move from one execution environment to another carrying both their code and their execution state. These execution environments can exist in a variety of devices in a data network including, but not limited to, servers, desktops, laptops, embedded devices, networking equipment and edge devices such as PDAs or cell phones. The characteristics of these platforms may vary widely in terms of computational capacity, networking capacity, display capabilities, etc. An agent must be able to adapt to these conditions.
Historically, agents have been programmed in a procedural manner. That is, agents are programmed with a series of steps that will ultimately result in a goal being achieved. This approach has limitations though as the logic for each agent must be compiled into the agent software and is therefore static. Complex goals can also become intractable for a programmer as the set of rules the agent must follow grows.
Rule-Based Systems
In his tutorial, Introduction to Rule-Based Systems, James Freeman-Hargis defines a rule-based system to consist of a set of assertions and a set of rules for how to act on the assertion set. When a set of data is supplied to the system, it may result in zero or more rules firing. Rule based systems are rather simplistic in nature, consisting of little more than a group of if-then statements, but form the basis of many “expert systems.” In an expert system, the knowledge of an expert is encoded into the rule-set. When a set of data is supplied to the system, the system will come to the same conclusion as the expert. With this approach there is a clear separation between the domain logic (a rule set) and the execution of the agent. As mentioned, the procedural agent approach tightly couples the two.
The rule-based system itself uses a simple technique. It starts with a rule-set, which contains all of the appropriate knowledge encoded into If-Then rules, and a working memory, which may or may not initially contain any data, assertions or initially known information. The system in operation examines all the rule conditions (IF) and determines a subset, the conflict set, of the rules whose conditions are satisfied based on the working memory. Of this conflict set, one of those rules is triggered (fired). The rule that is chosen is based on a conflict resolution strategy. When the rule is fired, any actions specified in its THEN clause are carried out. These actions can modify the working memory, the rule-set itself, or do just about anything else the system programmer decides to include. This loop of firing rules and performing actions continues until one of two conditions are met: there are no more rules whose conditions are satisfied or a rule is fired whose action specifies the rule engine execution should terminate.
Rule-based systems, as defined above, are adaptable to a variety of problems. In some problems, working memory asserted data is provided with the rules and the system follows them to see where they lead. This approach is known as forward-chaining. An example of this is a medical diagnosis in which the problem is to diagnose the underlying disease based on a set of symptoms (the working memory). A problem of this nature is solved using a forward-chaining, data-driven, system that compares data in the working memory against the conditions (IF parts) of the rules and determines which rules to fire.
In other problems, a goal is specified and the system must find a way to achieve that specified goal. This is known as backward-chaining. For example, if there is an epidemic of a certain disease, this system could presume a given individual had the disease and attempt to determine if its diagnosis is correct based on available information. A backward-chaining, goal-driven, system accomplishes this. To do this, the system looks for the action in the THEN clause of the rules that matches the specified goal. In other words, it looks for the rules that can produce this goal. If a rule is found and fired, it takes each of that rule's conditions as goals and continues until either the available data satisfies all of the goals or there are no more rules that match.
The Rete algorithm is an efficient pattern matching algorithm for implementing forward-chaining, rule-based systems. The Rete algorithm was designed by Dr. Charles L. Forgy of Carnegie Mellon University in 1979. Rete has become the basis for many popular expert systems, including JRules, OPS5, CLIPS, JESS, Drools, and LISA.
A naïve implementation of a rule-based system might check each rule against the known facts in the knowledge base, firing that rule if necessary, then moving on to the next rule (and looping back to the first rule when finished). For even moderate sized rules and fact knowledge-bases, this naïve approach performs far too slowly.
The Rete algorithm (usually pronounced either ‘REET’ or ‘REE-tee’, from the Latin ‘rete’ for net, or network) provides the basis for a more efficient implementation of an expert system. A Rete-based expert system builds a network of nodes, where each node (except the root) corresponds to a pattern occurring in the left-hand-side of a rule. The path from the root node to a leaf node defines a complete rule left-hand-side. Each node has a memory of facts which satisfy that pattern.
As new facts are asserted or modified, they propagate along the network, causing nodes to be annotated when that fact matches that pattern. When a fact or combination of facts causes all of the patterns for a given rule to be satisfied, a leaf node is reached and the corresponding rule is triggered.
The Rete algorithm is designed to sacrifice memory for increased speed. In most cases, the speed increase over naïve implementations is several orders of magnitude (because Rete performance is theoretically independent of the number of rules in the system). In very large systems, however, the original Rete algorithm tends to run into memory consumption problems which have driven the design of Rete variants.
Therefore, what is needed is an ability to move an agent that utilizes environment resident rules from a first execution environment to a second execution environment. More specifically what is needed is movement of an agent that utilizes a merged set of supplied and environment resident canonical rules in a first execution environment to a second execution environment that includes a different set of environment resident rules.